fix(items): approve openclaw device pairing in-container - #7

Deploying this item produced a Control UI nobody could get into. The
browser authenticated, then stopped at "device pairing required
(requestId: ...)" and named a CLI on the Gateway host to approve it.

Device pairing is a second gate, evaluated only after gateway token auth
has already succeeded. A new browser's request can be approved only by an
already-paired admin session, and on a fresh deployment nothing is ever
paired -- so the item deadlocked, and the remedy the error names needs a
host shell a one-click deployment does not have. Neither the token nor
the origin allowlist was at fault; both already pass before this point.

Satisfy the gate rather than remove it. The component now runs a watcher
beside the gateway that polls `devices list --json` and approves pending
requests. Upstream anticipates this: `shouldPreserveLocalCliSharedAuthScopes`
carries a dedicated `cli_container_local` locality that preserves operator
scopes for a token-authenticated CLI inside the gateway's own container,
so `devices approve` works over loopback without pairing of its own.

Rejected `gateway.controlUi.dangerouslyDisableDeviceAuth`, which clears
the same gate by discarding device identity altogether: browsers keep
their device keypair and revocable device token this way, `openclaw
security audit` stays clean, and the mechanism survives 2026.8.x, where
that key is retired and inert and would silently restore the deadlock on
an image bump. Also verified against the pinned release that
`allowInsecureAuth` ("does not bypass pairing checks", localhost-only)
and `nodes.pairing.autoApproveCidrs` (never applies to browser clients)
are not alternatives, despite both being widely cited as such.

Two greps rather than a JSON parser because the image ships no jq and a
node -e script cannot be quoted inside this scalar. `requestId` appears
only on pending entries -- paired rows carry deviceId, displayName,
roles, scopes, tokens and IP -- so the match cannot touch an existing
device.

The listing's claim that you just enter the token on first visit was
false for every deployment; it now describes both gates and says plainly
that the token is what guards an admin surface.

Verified: typecheck clean, full corpus 377/377; the folded scalar
resolves to one well-formed shell string whose --batch-json argument
parses as the three intended ops; `sh -n` accepts the inner script; and
the grep pipeline extracts exactly the pending requestId from a payload
carrying both a pending entry and a paired device, ignoring the latter's
UUID. Not verified -- no container runtime in the devcontainer: the live
smoke test that the watcher actually clears the pairing screen.

Closes #6

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpjD9Pkxh8LBhJPJQLzpx3

…ring watcher

Replace the in-container `devices approve` watcher with
`gateway.controlUi.dangerouslyDisableDeviceAuth`. The intended posture for
this item is that anyone holding the gateway token gets in from any
browser, with no device enrolled or allowlisted, and no background process
load-bearing for reachability.

Gateway auth is untouched, despite the key's name. Reading the connect
path in the 2026.7.1 bundle, three gates run in order: device identity
(allowBypass admits), then an unconditional
`if (!authOk) { rejectUnauthorized(authResult); return; }`, then the
pairing gate (allowBypass skips). Gate two carries no isControlUi test and
no allowBypass exemption and sits between the two the key affects, so the
token check stays fully enforced while device identity and pairing go
away.

The watcher it replaces worked and was confirmed live, but it made
reachability depend on a polling loop and put a cold CLI start in front of
every first connect. Traded for a declarative key and an instant first
load. The cost is stated in both files: no second factor, no per-device
revocation, and browsers re-present the token each session rather than
holding a stored device token.

The image tag is now load-bearing and says so. 2026.7.1 is the last stable
release honouring this key: its `shouldSkipControlUiPairing` ends
`return role === "operator" && policy.allowBypass`, while 2026.8.1 and
2026.8.2 both end `return null`, and upstream calls the key "a retired
break-glass input, now fully inert" with `doctor --fix` deleting it. On
2026.8.x the controlUi schema no longer offers a device-auth toggle at
all, and the surviving bypasses are trusted-proxy `deviceAutoApprove`
(needs an identity-injecting edge) or node-role pairing policy (excludes
browsers). A tag bump therefore silently restores the deadlock; the
comment says what has to change alongside it.

Verified: full corpus 377/377, typecheck clean, `sh -n` accepts the inner
script, and the folded scalar resolves to four config ops with
dangerouslyDisableDeviceAuth carried as a JSON boolean rather than a
string.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpjD9Pkxh8LBhJPJQLzpx3